Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
This is a proof of concept for metrics suggested by SELinuxMount feature.
Using these metrics I think with lot of joins and label replaces I can detect if two containers use the same volume in parallel, and the containers have the same SELinux label (good) or a different one (bad, those Pods will not run when SELinuxMount gets enabled).
New metrics:
kube_pod_security_context
: pod'sspec.securityContext
fields. The only values I need areseLinuxOptions
.kube_pod_container_security_context
: pod'sspec.containers[*].securityContext
fields. I needprivileged
flag +seLinuxOptions
.kube_pod_container_volume_mount
: report volumes used by containers. The existingkube_pod_spec_volumes_persistentvolumeclaims_info
tracks volumes used in pods.kube_csidriver_info
: report CSIDriver object fields. I need justseLinuxMount
flag.WIP. TODO when the KEP is approved:
SecurityContext
,PodSecrutyContext
andCSIDriver
fields are useful?spec.securityContext.seLinuxChangePolicy
tokube_pod_security_context
.kube_persistentvolume_unique_volume_id
.kube_persistentvolume_info
does misses some volume types (e.g. in-tree vSphere or Cinder) and is declared STABLE. And it's clumsy to work with.How does this change affect the cardinality of KSM: increases
(no change to any existing metric, new metrics do have nozero cardinality)
KEP update proposal: kubernetes/enhancements#4843